本文来自陈皓在知乎的问答，关于《如何看待Linus“从不认为阅读别人的代码是了解某个想法的一种有用的方法”言论？》

Jeff Atwood说过这么一句话：

Code Tells You How, Comments Tell You Why.

其实，Jeff这句话并不准确，另外，我把其扩展一下

• 代 码 => What, How & Details
• 文档/书 => What, How & Why

可见，代码并不会告诉你 Why，看代码只能靠猜测或推导来估计 Why，都是臆想，不准确，也会有很多误解。 而且，我们每个人都知道，Why 这个东西是让你一通百通的东西，也是让人醍醐灌顶的东西。（ 这也是楼主为什么喜欢看书的原因，我也是）

但是，代码会告诉你细节，这是书和文档不能给你的，细节是魔鬼，细节决定成败，这样的话我们不但听过很多了， 我们做技术的也应该体会过很多了。当然，我们也要承认，这些代码细节给人带来的快感毕竟不如知道 Why 后的快感大 （至少对我是这样的）。

书和文档是人对人说的话，代码是人对机器说的话。所以，如果你想知道人为什么要这么搞，那么你应该去看书， 看文档（就像 Effective C++、Code Complete、Design Pattern、Thinking in Java 等等这样的书）, 如果你要知道让机器干了什么？那你应该看代码！(就像 Linus 去看 zlib 的代码来找性能问题) 因此，我认为都比较重要，关键看你的目的是什么了。如果，你想要了解一种思想，一种方法，一种原理， 一种思路，一种经验，恐怕，读书和读文档会更有效率一些，因为其中应该会有作者的思路的描述。比如像 Effective C++之类的书，里面有很多对不同用法和设计的推敲，像 TCP/IP 详解里面也会对 TCP 算法的好坏的比较…… 这些思维方式能让你对技术的把握力更强。 光看代码很难达到这种级别。（现在你知道什么样的书是好书了吧 ;-)）

如果，你想了解的就是具体细节，比如：某协程的实现，某个模块的性能，某个算法的实现。 那么，你还是要去读代码的。因为代码中会有更具体的处理（尤其是对于edge case或是一些代码技巧的东西）。

另外，看看下面的几个现像，你可以自己比较一下： 很多时候，我们去读代码，那是因为没有文档，或是文档写得太差。 很多时候，你在 google, stackoverflow, Github 过后，你会发现，你掌握的知识就是一块一块的碎片， 即不系统，也不结构化，更别说融会贯通了。你会觉得你需要好好地读一本书，系统地掌握知识，这种感觉你一定很强烈吧。 很多时候，在你去读别人代码的时候，你会因为基础知识或是原理不懂，或是你不知道为什么的情况下，你要么完全读不懂代码， 要么就是会误解代码。（比如：如果你没有 C 语言和 TCP 原理的基础，你根本读不懂 linux下TCP 的相关代码的。 我们因为误解代码用意而去修改代码造成的故障还少吗？）很多时候，看到一个算法时或是一个设计时，比如 Paxos 这样的，你是不是会有想去看一下这个算法的实现代码是什么样的？如何才能实现的好？ 很多时候，当你写代码的时候，你能感觉得到自己写的代码有点别扭，怎么写都别扭，这个时候， 你也会有想去看别人的代码是怎么实现的冲动。

…… ……

从代码中收获得大，还是从书中收获的大，不同的场景不同的目的下会有不同的答案。 这里，谈一谈人的学习过程吧，从学习的过程中，我们来分析一下看代码和看书这两个活动。

人对新事物的学习过程基本都是从 “感性认识” 到 “理性认识” 的。 如果你是个新手，那应该多读代码，多动手写代码，因为你需要的是“感性认识”，这个时候 “理性认识” 对你来说你体会不到。一是因为，你没有切身的感受，告诉你 Why 你也体会不到，另一方面，这个阶段，你要的不是做漂亮，而是做出来。 所以，在新手这个阶段，你会喜欢 Github 这样的东西。

如果你是个老手，那么你有多年的 “感性认识”了，你的成长需要更多的 “理性认识”， 因为这个阶段，一方面，你会不满足于做出来，你会想去做更牛更漂亮的东西，另一方面，你知道的越多，你的问题也越多， 你迫切地需要知道 Why！这个时候，你就需要大量的找牛人交流（读牛人的书，是一种特殊的人与人的交流）， 所以，这个阶段，你会喜欢读好的书和文章的。然而，对于计算机行业这个技术创新超强技术繁多的行业来说：

我们每个人都既是新手，也是老手。